Resposta Manuscrita Transcrita:
"O Professor Agente é um projeto, isso é evidenciado na execução descrita, onde existem características de desempenho esperado (tempo de resposta), conexão com a API e a sprint"
Parecer do Docente:
Classificou como Projeto, mas as justificativas apresentadas citam requisitos funcionais de execução e conexão, sem articular as características ontológicas do Cap. 1 (resultado único, temporalidade ou restrição de recursos). Pontuação: 0,8 / 1,5.
Resposta Manuscrita Transcrita:
"Reduzir os testes automatizados vai requerer menos do P.O e do Dev que são 'responsáveis', mas diminuirá a chance de encontrar erros, assim como diminuirá o custo de tempo que levaria para realizar os testes e o custo geral. Tudo isso não vale a pena pois a qualidade diminuirá."
Parecer do Docente:
A discente analisou as consequências de cortar testes, mas o comando solicitava expressamente propor duas alternativas de trade-off sem sacrificar qualidade (ex: negociar escopo, estender prazo ou alocar mais recursos). Pontuação: 0,5 / 2,0.
Resposta Manuscrita Transcrita:
"Seria híbrida, pois considerando o tempo de aula e a duração de cada sprint a cada duas semanas teríamos duas aulas, logo 7 sprints. O ciclo de vida pode ser mais ágil em cada sprint, mas como um todo sendo híbrido."
Parecer do Docente:
Classificou como ciclo Híbrido e articulou a cadência de aulas com as sprints. Faltou aprofundar na resposta à incerteza da IA. Pontuação: 1,0 / 1,5.
Resposta Manuscrita Transcrita:
[Diagrama: 3 blocos: autenticação, interface e integração, armazenamento e dashboard com tarefas subordinadas]
Parecer do Docente:
Identificou 3 grandes blocos estruturais no quadro. Contudo, utilizou verbos nas folhas subordinadas e omitiu completamente o texto conceitual explicativo da Regra dos 100%. Pontuação: 0,75 / 1,5.
Resposta Manuscrita Transcrita:
"Issue 1 (título: autenticação; descrição: cabe ao Dev realizar as seguintes tarefas de decidir a API utilizada e o canal de chat a serem utilizados; estimativa de tempo: 1 semana).
Issue 2 (título: interface e integração; descrição: cabe ao Dev fazer a integração com a LLM e em conjunto com P.O testar comandos básicos; estimativa de tempo: 1 semana).
A primeira issue leva menos tempo e menos esforço por se tratar de decisão, já a segunda requer trabalho prático que demanda + tempo e esforço."
Parecer do Docente:
Definiu as duas issues e articulou o esforço relativo entre decisão conceitual e implementação prática. Faltou detalhar critérios de aceitação verificáveis. Pontuação: 1,0 / 1,5.
Resposta Manuscrita Transcrita:
"As milestones não substituem sprints, o Kanban pode substituir sprints em cenários onde as tarefas estão devidamente divididas e os prazos bem estabelecidos."
Parecer do Docente:
Acertou ao constatar que milestones não substituem sprints. Na análise do Kanban, a justificativa foi simplista, pois o Kanban sem sprints é recomendado para fluxo contínuo sob demanda e não para projetos com datas fixas de cascata. Pontuação: 1,0 / 2,0.
Resposta Manuscrita Transcrita:
"Não, se os testes de segurança forem omitidos o chat não estará 'pronto', pois as verificações de qualidade serão omitidas. Os testes de segurança ao serem pulados comprometerão a validação de todas as funções fazendo com que os problemas não resolvidos agora aparecerão depois com maior impacto."
Parecer do Docente:
Excelente conclusão de que omitir testes viola o critério de pronto e posterga falhas críticas. Faltou enunciar a definição formal do DoD. Pontuação: 1,2 / 1,5.
Resposta Manuscrita Transcrita:
"(a) avaliação, (b) custo de prevenção, (c) falha interna, (d) falha externa. O mais alto seria a falha de segurança, pois a equipe deverá buscar no código todo e encontrar essa falha de segurança, além do tempo gasto corre risco do agente socrático ficar inativo por um tempo."
Parecer do Docente:
Houve inversão dos pares conceituais de CoQ: (a) é Prevenção, (b) é Avaliação, (c) é Falha Externa e (d) é Falha Interna. Pontuou pela justificativa do impacto da falha de segurança. Pontuação: 0,5 / 1,5.
Resposta Manuscrita Transcrita:
"Se os testes de segurança forem realizados corretamente, os impactos por erros/bugs serão menos recorrentes. Ao passo que a falta dos testes aumenta muito a incidência dos erros/bugs. Logo, para garantir verificações de qualidade eles são inegociáveis."
Parecer do Docente:
Defendeu a importância dos testes preventivos, mas omitiu a explicação da regra numérica 1:10:100 e a análise dos limites específicos da heurística em IA (não-determinismo). Pontuação: 0,6 / 2,0.
Resposta Manuscrita Transcrita:
"Esse evento era um risco que se tornou um problema na execução do projeto. Pois não é algo que é evitado durante a execução e por falha acaba acontecendo. É baixa a probabilidade de alguém vazar a chave, mas se acontecer pode atrasar o andamento do projeto, não sendo tão crítico." [Matriz marcada no quadrante Probabilidade Baixa × Impacto Médio].
Parecer do Docente:
Diferenciou risco de problema. Considerou o impacto apenas como 'atraso moderado', subestimando o risco financeiro e de segurança que torna o vazamento de API crítico. Pontuação: 1,0 / 1,5.
Resposta Manuscrita Transcrita:
"Correção do código; Reunião para alinhar o ocorrido; Mudar a chave; Para uma ação preventiva seria alertar todos dessa possibilidade e documentar isso."
Parecer do Docente:
Ações imediatas incluíram rotação da chave. Na ação preventiva, recomendou conscientização e documentação, sem propor medidas técnicas automatizadas (como .gitignore ou scanners de segredos no CI/CD). Pontuação: 0,8 / 1,5.
Resposta Manuscrita Transcrita:
"Um risco de entrada seria o prompt injection que é causado por falha na construção da segurança, a probabilidade é média e o impacto é crítico. A mitigação seria melhorar o código para que a segurança seja restaurada. Para um risco de saída como alucinação seria mudar o estilo de resposta do agente e registrar isso nas especificações de apresentação do ReadMe."
Parecer do Docente:
Modelou o risco de entrada e saída. Contudo, recomendou o README em vez do ADR (Architecture Decision Record) formal para documentar decisões técnicas de arquitetura. Pontuação: 1,25 / 2,0.
Resposta Manuscrita Transcrita:
"Na comunicação síncrona semanal (como fazemos no nosso grupo) é possível alinhar melhor as tarefas e concretizar o ponto em que estamos do nosso projeto, além de tirar dúvidas entre si. Já a assíncrona, por mais que tenha cada responsável e prazos o controle é menor se comparado ao síncrono. Logo, o melhor cenário é combinar as reuniões síncronas semanais e as issues e etc pelo git lab também semanalmente."
Parecer do Docente:
Boa comparação prática fundada na experiência da equipe combinando reuniões de alinhamento com issues no GitLab. Pontuação: 1,1 / 1,5.
Resposta Manuscrita Transcrita:
"Para o professor que é cliente e patrocinador as reuniões síncronas mensais para mostrar os resultados e progressos são importantes. Elas podem ser feitas por canais de comunicação como o Google Meet."
[Diagrama: (1, 2) Manter satisfeito; (3) Gerenciar de perto; (4) Monitorar; (5) Manter informado]
Parecer do Docente:
O professor (2) deve figurar em Gerenciar de perto por deter alto poder e alto interesse, e a coordenação (5) em Manter satisfeito. A frequência mensal proposta para o professor é insuficiente em projeto de 5 sprints. Pontuação: 0,65 / 1,5.
Resposta Manuscrita Transcrita:
"Nenhum dos dois cenários apresentados seria o mais adequado, pois ambos os modelos de resposta estão sujeitos a alucinações da I.A. O certo seria uma resposta curta e teórica (treinada) para que evite alucinações"
Parecer do Docente:
A discente analisou o problema de engenharia da resposta curta vs longa, mas não aplicou a grade conceitual dos Modos de Conflito de Thomas-Kilmann solicitada no enunciado. Pontuação: 0,4 / 2,0.
